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CONFIGURATION OPTIONS FOR TRANSACTION PROCESSING 

CROSS-REFERENCE TO RELATED APPLICATION 
This application claims priority to co-pending U.S. provisional application serial 
number 60/214,987, filed June 29, 2000, which is entirely incorporated herein by reference. 

TECHNICAL FIELD 
The present invention is generally related to television systems, and, more 
particularly, to the field of transaction options. 

BACKGROUND OF THE INVENTION 
Media service systems have awakened, through advancements in transmission and 
communications technology, to provide subscribers with a plethora of media content never 
before possible. Along with the advent of a distribution of a wide variety of media content, 
comes a wide range of choices for the subscriber. Many advanced media service systems 
provide a programming guide to allow the subscriber to acquire information about the 
subscriber's media content choices. 

A typical media service system involves a central headend unit distributing a plurality 
of instances of media content over a transmission system, usually a cable or satellite network, 
to a multitude of client devices, such as a settop, as one example among others. Each client 
device contains the necessary hardware and software to interpret a transmission from the 
network and provide that transmission to be presented by a presentation device, such as a 
television, among other examples. The client device is also enabled to accept commands 
from the subscriber regarding the display of certain choices of media content. Certain 
choices by the subscriber require the client device to communicate with the central headend 
to request desired services. 

One type of media content choice by a subscriber involves renting a movie 
presentation. Many media service systems will allow a subscriber to rent a movie 
presentation to be displayed at a time provided by the system. The subscriber will view 
information concerning a desired movie and then proceed to enter a buy sequence. The buy 
sequence usually begins when the subscriber indicates a desire to purchase a particular 
movie. Next, the client device will enter a process by which the purchase is validated and 
confirmed. In this process, the client device will usually require the subscriber to confirm the 
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purchase and enter authentication information, such as a Personal Identification Number 
(PIN). The client device may thus require the subscriber to complete multiple confirmations 
to confirm that the movie presentation purchase is truly desired before the purchase will be 
executed. 

5 Although there may be a wide variety of various types of media content available, the 

buy sequence for different types of media content most often remains the same. Not only 
does the media content vary greatly, but the characteristics and desires of the subscribers 
using the system varies by an even greater degree. Despite the wide range of variances in 
types of product, people, and purchases, the sequence required to buy media content remains 
10 unadaptable. 

Thus, a heretofore unaddressed need exists in the industry to address the 
aforementioned deficiencies and inadequacies. 

~ SUMMARY OF THE INVENTION 

15 In one embodiment of the present invention, a media service system provides at least 

one transaction configuration option that is enabled to be selected by a user. The media 
service system implements a transaction process in response to a user selection. 

Other systems, methods, features, and advantages of the present invention will be or 
become apparent to one with skill in the art upon examination of the following drawings and 

20 detailed description. It is intended that all such additional systems, methods, features, and 

advantages be included within this description, be within the scope of the present invention, 
and be protected by the accompanying claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The accompanying drawings, incorporated in and forming a part of the specification, 

25 illustrate several aspects of the preferred embodiments of the present invention, and together 

with the description serve to explain the principles of the preferred embodiments of the 
invention. The components in the drawings are not necessarily to scale, emphasis instead 
being placed upon clearly illustrating the principles of the preferred embodiments of the 
present invention. Moreover, in the drawings, like reference numerals designate 

30 corresponding parts throughout the several views. The reference numbers in the drawings 

have at least three digits with the two rightmost digits being reference numbers within a 
figure. The digits to the left of those digits are the number of the figure in which the item 
identified by the reference number first appears. For example, an item with reference number 
209 first appears in FIG. 2. In the drawings: 
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FIG. 1 is a block diagram of a high level view of the architecture of the media service 
system in accordance with one preferred embodiment of the present invention. 

FIG. 2 is a block diagram illustrating the headend of the media service system of FIG. 
1 in accordance with one preferred embodiment of the present invention. 
5 FIG. 3 is a block diagram illustrating the client device of the media service system of 

FIG. 1 in accordance with one preferred embodiment of the present invention. 

FIG. 4 is a block diagram illustrating the client command device of the media service 
system of FIG. 1 in accordance with one preferred embodiment of the present invention. 

FIG. 5 is a diagram depicting an example of a transaction configuration options screen 
1 0 enabled by the transaction configuration module of FIG. 1 in accordance with one preferred 

embodiment of the present invention. 

FIG. 6 is a diagram depicting an example of a first time subscriber registration screen 
I enabled by the transaction configuration module of FIG. 1 in accordance with one preferred 
embodiment of the present invention. 
15-: FIG. 7 is a diagram depicting an example of a purchase options and reminder options 

screen enabled by the transaction configuration module of FIG. 1 in accordance with one 
preferred embodiment of the present invention. 

FIG. 8 is a diagram depicting an example of a reminder options screen enabled by the 
transaction configuration module of FIG. 1 in accordance with one preferred embodiment of 
20-. the present invention. 

FIG. 9 is a diagram depicting an example of a video on demand transaction 
configuration options screen enabled by the transaction configuration module of FIG. 1 in 
accordance with one preferred embodiment of the present invention. 

FIG. 1 OA is a diagram depicting an example of a PIN entry screen enabled by the 
25 transaction configuration module of FIG. 1 in accordance with one preferred embodiment of 

the present invention. 

FIG. 1 OB is a diagram depicting an example of a multiple PIN entries screen enabled 
by the transaction configuration module of FIG. 1 in accordance with one preferred 
embodiment of the present invention. 
30 FIG. 1 1 is a diagram depicting an example of a video on demand screen illustrating a 

notification icon enabled by the transaction configuration module of FIG. 1 in accordance 
with one preferred embodiment of the present invention. 
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FIG. 12 is a diagram depicting an example of a video on demand screen illustrating a 
notification barker enabled by the transaction configuration module of FIG. 1 in accordance 
with one preferred embodiment of the present invention. 

FIG. 1 3 is a diagram depicting an example of a subscriber profile setup screen 
enabled by the transaction configuration module of FIG. 1 in accordance with one preferred 
embodiment of the present invention. 

FIG. 14 is a diagram depicting an example of administrative configuration settings 
enabled by the administrative transaction configuration module of FIG. 1 in accordance with 
one preferred embodiment of the present invention. 

FIG. 1 5 is a diagram depicting an example of administrator user interface enabled by 
the administrative transaction configuration module of FIG. 1 in accordance with one 
preferred embodiment of the present invention. 

FIG. 16 is a diagram depicting an example of a remote subscriber user interface 
screen illustrating one implementation of the subscriber user interface of FIG. 1 in 
accordance with one preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
The preferred embodiment of the present invention provides transaction configuration 
options to the users of a media service system. An option will be understood to include an 
element, which will provide a certain feature when selected. In a non-limiting example, this 
feature could provide a benefit to the users of the system or method described herein. A 
transaction will be understood to mean the action that takes place during the purchase of an 
item or a sequence of actions that take place during the purchase of an item. A transaction 
configuration option is an option that determines the action or sequence of actions that take 
place during the purchase of an item. A transaction process is understood to mean a process 
that transpires prior to the consummation of a purchase and that is instantiated by a user 
exercising a step or set of steps comprised in one or many transaction configuration options 
that were selected to determine the action or actions that take place during the purchase of an 
item. A user is understood to be anyone who utilizes the system or method described herein 
and can be, in accordance with various embodiments, an administrator or a subscriber. An 
administrator is typically one who controls the system or method described herein, such as, 
for example, a system operator located at a system headend. A subscriber is typically a 
customer or local user of a client device in the system or method described herein. Selections 
are indications of choices made by a user. A purchase refers to the act of buying an item, 
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such as, for example, an entity, media content, or event, the act of renting an item for a 
period, and/or the act of gaining the right to view an item for a period of time. The term 
media is used synonymously with the term media content and is herein used to describe any 
type of entertainment, news, event, etc. that can be presented to a person. 
5 Reference will now be made in detail to the description of the preferred embodiments 

of the invention as illustrated in the drawings. While the various embodiments of the 
invention will be described in connection with these drawings, there is no intent to limit it to 
the embodiment or embodiments disclosed therein. On the contrary, the intent is to cover all 
alternatives, modifications, and equivalents included within the spirit and scope of the 

10 invention as defined by the appended claims. All examples, embodiments, implementations, 

etc., are understood to be non-limiting and among others. 
~r FIG. 1 depicts the general architecture of a media service system 1 10 in which a 

subscriber television system (STS) headend 120 provides media content over an STS 
- transmission system 130 to numerous client devices 140. Each client device, such as client 

15 " device 140A, interprets information received from the STS headend 120 via the STS 

transmission system 130 such that it can be provided to the presentation system 15 OA and 
then presented to the subscriber. The client command device 160A enables the subscriber to 
provide commands to the client device 140 A. With the client command device 160 A, the 
subscriber can enter input to effect the presentation that is to be displayed on the presentation 

20 system 150A. 

The presentation system 150A can be any system that enables a user to experience a 
session provided by the client device 140A. The presentation system 150A can be, for 
example but not limited to, a television, a computer monitor, a projection unit, or a simulator 
providing visual and audible stimulation. The presentation system 1 50A processes 

25 information from the client device 140 A. The presentation system 1 5 OA processes the 

information such that it can be viewed, heard or otherwise presented to the senses of the user. 
The user is able to perceive the information in the subscriber user interface 1 80 through the 
use of the presentation system 1 50A. Furthermore, the user can effect the information in the 
subscriber user interface 180 to be presented by the presentation system 150A by entering 

30 input with the client command device 160A. The user is able to give commands to client 

device 140 A to interact with the transaction configuration module 100 with a client command 
device 1 60A. The client command device 1 60A can be any entity that relays user input to the 
client device 140 A. Examples of the client command device 160 A include, among others, a 
remote control, a wired or wireless keyboard, a mouse, and a voice command device. The 
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commands given by the client command device 160 A dictate, among other things, the 
execution of certain actions within the subscriber user interface 180. With the use of the 
client command device 160A and the presentation system 150A, the user can experience and 
interact with the subscriber user interface 180. In an alternate embodiment of the system 
5 depicted in FIG 1, the client device 140A and the presentation system 150 A can be 

implemented in the same device. In addition, the client command device 160 A could be 
incorporated into an entity containing the client device 140 A and/or the presentation system 
150A. 

The client command device 160A preferably allows the subscriber to utilize the 

10 functionality of the client device 140A. Using the client command device 160 A, the 

subscriber can, among other things, navigate and scroll through media content guides and 
make selections. The media service system 110 enables the subscriber to interact with the 
system with regard to particular services. The media service system 110 provides 
programming that is accessible with interactive user inputs such as, for example but not 

1 5 limited to, broadcast pay-per view programming, and broadcast near video on demand 

(NVOD). Furthermore, the media service system 1 10 provides on demand programming that 
is also accessible with interactive user input such as, for example but not limited to, video on 
demand (VOD), internet applications, and/or interactive media guides (IMG). The subscriber 
may navigate different guides, information, and programs in a subscriber user interface 180 

20 to gain information and to learn about available items. If the subscriber discovers an item of 

interest that requires or allows a purchase, then that subscriber may enter and complete a 
transaction for purchasing the item of interest. This transaction may involve one or more 
steps, execution of which is required to complete the purchase of the item desired. 

With access to varied applications, including access to the internet, it is possible for a 

25 subscriber to complete purchases for many kinds of goods and services in addition to media 

content services. The discussion herein shall focus upon transactions for media content 
purchases, but the scope of the present invention is not limited thereto and extends to 
virtually all types of purchases. 

In one embodiment of the current invention, the transaction configuration module 100 

30 is enabled to configure transaction processes. The term "user" is used herein with reference 

to this embodiment to refer to administrators of the media service system 1 1 0, as well as 
subscribers of the media service system 110, and the configuration can be performed by 
either. The transaction configuration options module 100 is illustrated in FIG. 1 as an entity 
within client device 140 A. It should be clear to one of ordinary skill in the art that the 
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transaction configuration options module 100 could be implemented in various ways. 
Examples include, among others, an independent unit, a logic module within the client 
command device 160 A, a software logic module within the STS headend 120, a module 
within the STS transmission system 130, or a logic module within any device in the media 
5 service system 110. Furthermore, a distributive transaction configuration module 100 could 

be implemented in various ways such as, for example but not limited to, part in the STS 
headend 120 and part in the client device 140A. 

In one embodiment of the present invention, the administrator, or system operator, of 
the media service system 1 10 can determine what types of transaction options are provided to 

10 the subscriber by controlling the media service system 1 1 0 through the administrative 
transaction configuration module 170. In one implementation of this embodiment, the 
administrative user interface 170 provides the administrator with an interface from which the 
administrator can select transaction configuration options that configure the set of transaction 
configuration options that are available to the subscriber through the transaction 

15 -= configuration module 100. A transaction configuration option can constitute the inclusion of 
a step or steps in the sequence of steps required by a transaction process. Likewise, a 
transaction configuration option can constitute an omission of a step or steps in the sequence 
of steps required by a transaction process. In one implementation, as shall be described in 
greater detail below, the administrator can define certain transaction configuration options to 

20 be available to designated regions of the network and even to a particular one of the client 

devices 140. 

In one implementation of this embodiment, the subscriber is able to access the 
transaction configuration module 1 00 through the subscriber user interface 1 80. Using the 
subscriber user interface 1 80, the subscriber may also determine the manner in which a 

25 transaction is completed for one or more future purchases. In one embodiment, the 

subscriber may enter selections with the client command device 160A of certain transaction 
configuration options made available by the administrator. By choosing among the options 
made available to that particular client device by the administrator, the subscriber determines 
the transaction process. In one embodiment, the transaction configuration module 1 00 

30 creates a specified transaction process by implementing the options selected by the 

subscriber. In this manner, when a particular subscriber requests a certain type of item, then 
that subscriber will be required to complete the specified transaction process in order to 
purchase the chosen item. 
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In an example implementation, a global set of transaction configuration options could 
be provided by the administrative transaction configuration module 170 to the administrator. 
The administrator could select a subset of transaction configuration options, herein with 
reference to this implementation referred to as a client set, from among the global set of 
5 transaction configuration options. Thus, enabling only those transaction configurations 

options in the client set to be presented to the subscriber. Thereby, the subscriber could be 
provided with the client set of transaction configuration options by the transaction 
configuration module 100. The subscriber could then select the desired transaction 
configuration options. In addition, the subscriber can select to omit undesired transaction 
10 configuration options. Those options selected by the subscriber would be implemented as a 
transaction process. Therefore, the steps involved in the transaction process thereafter could 
-- be determined by the transaction configuration options selected by the subscriber. In a non- 
_ : limiting example, this transaction process would then be executed by the client device 140A 
Z whenever the subscriber indicates a desire to purchase an item. In another non-limiting 
1 5 - example, this transaction process might be associated with a particular type of purchasable 
item, such as a movie. In this example implementation, the subscriber would be required to 
complete the steps of this movie transaction process to complete a movie purchase. 

In one embodiment of the invention, the administrator pre-configures a plurality of 
transaction processes, each transaction process comprising a respective set of steps required 
20 to be conducted during a purchase by the subscriber. Alternatively, the administrator can 

select a subset of transaction processes from a global set provided by the administrative 
transaction configuration module 170. Thereby, the subscriber selects one from a plurality of 
pre-configured transaction processes to be implemented as a transaction process for future 
transaction purchases. 

25 In an alternate embodiment, the subscriber is allowed to deselect respective steps in a 

subscriber-selected pre-configured transaction process. Certain steps of a pre-configured 
transaction process may be de-selectable while others may not. 

A first transaction process, be it either a subscriber-selected pre-configured 
transaction process or a subscriber-configured transaction process, may be configured to be 

30 associated with a first type of media content service. Thereafter, the first transaction process 

becomes active only during the purchase of a first type of media content service. A second 
transaction process may be configured to be associated with a second type of media content 
service and thus becomes active only during the purchase of a second type of media content 
service. A third transaction process may be configured to be associated with a plurality of 
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types of media content services and thus becomes active only during the purchase of any of 
the respective types of media content services. 

In one embodiment, the set of permissible associations between types of media 
content services and transaction processes that a subscriber can configure is designated a 
5 priori by the administrator. The administrator either selects and enables a plurality of types 

of media content services that can be associated with each respective transaction process, 
and/or a plurality of transaction processes that can be associated with each respective media 
content service. 

FIG. 2 depicts an implementation of the STS headend 120A in accordance with one 

10 embodiment of the present invention. STS headend 120A is configured to provide numerous 
functionalities to the client devices 140 (FIG. 1). One of these functionalities is the media 
service system 1 10 (FIG. 1). In a non-limiting example, the media service system 110 (FIG. 
: 1) is controlled from the headend by a computer shown as the digital network control system 
- (DNCS) 213. The DNCS 213 includes an administrative transaction configuration module 

15 170 that is responsible for reserving and configuring system resources needed to provide 

configuration and service data to the transaction configuration module 100 (FIG. 1). In an 
alternate implementation, the administrative transaction configuration module 170 exists 
separate from the DNCS 213. 

The DNCS 213 provides complete management, monitoring, and control of the 

20 network's elements and broadcast services provided to users. The DNCS 213 controls the 

content servers 21 1 that drive the video & data pumps providing on demand media content to 
the STS transmission system 130 as well as the infrastructure for broadcast media services 
such as PPV and NVOD. In one implementation, the DNCS 213 uses a data insertion 
multiplexer 212 and a data QAM 214 to insert in-band broadcast file system (BFS) data in to 

25 a MPEG-2 transport stream that is broadcast over the STS transmission system 130 to the 

client devices 140 (FIG. 1). The content servers 211 house the video & data pumps which 
supply media content to the client devices 140 (FIG. 1) through the QAM group 215. The 
QPSK modem 217 can be utilized to transport the out-of-band datagram traffic between the 
STS headend 120 A and the client devices 140 (FIG. 1). Through the use of the control and 

30 management devices in the STS headend 120A, an administrator can control the services 

provided by the system and more specifically the media service system 1 10 (FIG. 1). 

A service application manager (SAM) server 220 is a server component of a client- 
server pair of components, with the client component being located at the digital home 
communications terminal (DHCT) 140A (FIG. 3). Together, the client-server SAM 
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components provide a system in which the user can access services, which are identified by an 
application to run and a parameter, such as particular data content, specific to that service. The 
client-server SAM components also manage the life cycle of the applications on the system, 
including the definition, activation, and suspension of services they provide and the 
5 downloading of the applications into the DHCT 140A (FIG. 3) as necessary. With the use of 

SAM Server 220 and the client-server SAM components, a subscriber's DHCT 140 A (FIG. 3) is 
able to access services such as NVOD, VOD, pay-per view, electronic program guides (EPG), 
digital music, and media on demand (MOD). 

Applications on both the STS headend 120A and the DHCT 140 A (FIG. 3) can access 

10 the data stored in a broadcast file system (BFS) Server 219 in a similar manner to a file 

system found on operating systems. The BFS server 219 is a part of a broadcast file system 
that has a counterpart BFS client module in a DHCT 140A (FIG. 3) connected to the STS 
transmission system 130. The BFS server 219 repeatedly sends data for applications on a 
data carousel over a period of time in cyclical repeated fashion so that a DHCT 140A (FIG. 3) 

15 may read any particular data file or parts thereof, and receive it and store it in memory 320 

(FIG. 3). Reception of such data may be a result of a subscriber request or instigated by one 
or more application or internal processes in DHCT 140A (FIG. 3). Data, such as transaction 
configuration options and transaction processes, is accessed from memory 320 (FIG. 3) and if 
necessary converted to a displayable format for inclusion as a part of the subscriber user 

20 interface 180 (FIG. 1). 

The STS headend 120 A depicted in FIG. 2 is merely provided as an example 
implementation. The STS headend 120A could be implemented in many other ways without 
many of the components depicted in FIG. 2 and with many more additional components. 
FIG. 3 is a diagram depicting an implementation of one of the client devices 140 

25 (FIG. 1) in accordance with one embodiment of the current invention. The device depicted in 

FIG. 3 is DHCT 140A, a specific implementation of one of the client devices 140 (FIG. 1). 
The DHCT 1 40A is typically situated within a residence or business of a user. It may be 
integrated into a device that has a display unit, such as a television set, or it may be a stand- 
alone unit that couples to an external display. The DHCT 140A includes a processor 310 for 

30 controlling operations of the DHCT 140 A, a video output port such as an RF output system 

364 for driving the presentation system 150A, and tuner system 362 for tuning into a 
particular television channel to be displayed for sending and receiving various types of data 
from the STS headend 120A. The tuner system 362 includes, in one implementation, an out- 
of-band tuner for bi-directional Quadrature Phase Shift Keying (QPSK) data communication 
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and a Quadrature Amplitude Modulation (QAM) tuner for receiving television signals. 
Additionally, DHCT 140A includes a receiver for receiving externally generated information, 
such as user input from a client command device 1 60A. In this implementation shown in 
FIG. 3, the client command device 160A is a remote control. Other types of client command 
5 devices such as a keyboard, a mouse, or a voice command device may also provide the user 

inputs. The DHCT 140A may also include one or more wireless or wired communication 
interfaces, also called ports, for receiving and/or transmitting data to other devices. 

Memory 320, such as non-volatile (i.e., SRAM or FLASH memory) and dynamic 
random access memory (DRAM), is coupled to the processor 310 and stores operation 

1 0 parameters, such as commands that are recognized by the processor 310. The most basic 

functionality of the DHCT 140A is provided by an operating system 330 that operates in 
memory 320. One or more programmed software applications, herein referred to as 
applications, are executed by utilizing the computing resources in the DHCT 140A. The 
application executable program stored in memory 320 is executed by processor 310 (e.g., a 

1 5 central processing unit or digital signal processor) under the auspices of the operating system 

330. Data required as input by the application program is stored in memory 320 and read by 
processor 310 from memory 320 as need be during the course of application program execution. 
Input data may be data stored in memory 320 by a secondary application or other source, either 
internal or external to the DHCT 140 A, or may have been created with the application program 

20 : at the time it was generated as a software application program. Data may be received via any of 
the communication ports of the DHCT 140A, from the STS headend 120A via the DHCT's 
network interface (i.e., the QAM or out-of-band tuners) or as user input via receiver 361 . In a 
non-limiting example, data in files that are broadcast from BFS server 219 can be received via 
the QAM and/or out-of-band tuners. Data generated by an application program is stored in 

25 memory 320 by processor 310 during the course of application program execution. 

In accordance with the embodiment depicted in FIG. 3, the transaction configuration 
module 100 is responsible for executing most functionality regarding the implementation of 
transaction processes for the media service system 110 (FIG. 1) in relation to DHCT 140 A. The 
transaction configuration module 100 is enabled to execute in accordance with the 

3 0 aforementioned interactions with, among other things, the memory 320, the processor 310, and 

the operating system 330. The requests made by the user via the client command device 160A 
are interpreted by the receiver 361, stored in memory 320, and assigned to the transaction 
configuration module 100 by the operating system 330. The transaction configuration module 
100 executes, on the processor 3 10, the commands provided by the user in addition to those 
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received through the communications interface 363 provided by the STS headend 120A. In 
addition to the received commands, the transaction configuration module 1 00 can also require 
that certain application specific stored information be executed by the processor 310. A non- 
limiting example is illustrated by the transaction process 340 stored as part of the configuration 
5 module 1 00. In one implementation, a transaction process 340 is a transaction process that was 

implemented by the transaction configuration module 100 based on selections by a subscriber 
among available transaction configuration options. Thereby, in this implementation the 
transaction process 340 could be executed in processor 310 in the DHCT 140A when the 
subscriber requested a purchase to be made. The DHCT 140A would require the subscriber to 

1 0 satisfy the steps of the transaction process 340 to fulfill the purchase. In other embodiments, 

there are no separate transaction processes and transaction processes proceed as a function of 
applications, such as, for example, video on demand. The transaction process could be dictated 
by the STS headend 120 or DHCT 140A as a bit setting in the memory sequence for an 
application, such as, for example, video on demand. Thereby, the specific transaction process 

1 5 7 could be, in one implementation, a setting in the memory for the video on demand application to 
= ; not require a PIN entry. The transaction process could be other than a process as commonly 
■_f! understood, thus the transaction process could simply be a setting in an application. 

The subscriber database 350 depicted in FIG. 3 can be utilized to store information 
5 " relating to the subscribers who use the DHCT 1 40A. The subscriber database 350 depicted in 

20 .jr* FIG. 3 comprises of structured data such as a database, table of multiple fields, or data organized 
in memory 320 for purposes of retaining information pertinent to the transaction configuration 
module 1 00. Herein, database will refer to a database, structured data, or other data structures 
well known to those of ordinary skill in the art. As a non-limiting example, subscriber database 
350 includes subscriber personal information, subscriber registration, subscriber-selectable 

25 transaction configuration options, subscriber-selectable transaction processes, and subscriber- 

configured transaction processes, including associations between transaction processes and types 
of media content services. In one implementation, the subscriber database 350 is a designated 
area in memory 320 in which the transaction configuration module 100 can direct the 
information gathered about the subscriber to be stored for future use. In addition, the subscriber 

30 database 350 could further be utilized to store information concerning multiple subscribers using 

the DHCT 140A. In one implementation, the subscriber specific information could be employed 
for use in conjunction with a subscriber login option. The subscriber login option will be 
described in detail below. 
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In an example embodiment, the subscriber database 350 provides a designated area in 
memory 320 to store information necessary to complete a single execution transaction. A single 
execution transaction is one in which the user can initiate and complete an entire transaction 
to purchase an item with one execution. In a non-limiting example, when a subscriber finds a 
5 item that the subscriber would like to purchase, the subscriber can do so by executing a single 

step. Examples of this execution include, among others, a click of a mouse, a keystroke, a 
depression of a button on a remote, a tap of a touch screen, and a voice command. In one 
embodiment, the single execution transaction is made possible by accessing pre-stored 
information that is important in completing a purchase and for billing purposes. In a non- 
10 limiting example, the pre-stored information could be the subscriber's name, address, and 

billing information. In one implementation, this information could be stored in the subscriber 
database 350 and accessed by the DHCT 140A when a subscriber executes a single execution 
transaction. Alternatively, such information could also be stored and accessed at the STS 
headend 120 A since the subscriber already has a subscription with the STS headend 120A 
15 provider. 

The transaction configuration module 1 00 contains one or more transaction processes 
configured and activated by one or more subscribers that use DHCT 140A. In one 
embodiment, each stored transaction process contains information as to which media content 
service it is associated. 

20 The DHCT 140A depicted in FIG. 3 is merely provided as an example 

implementation of one of the client devices 140 (FIG. 1). The client devices 140 (FIG. 1) 
could be implemented in many other ways without many of the components depicted in FIG. 
3 and with many more additional components. 

FIG. 4 is a diagram depicting an example of a client command device 160A in 

25 accordance with one embodiment of the current invention. Certain keys on the client 

command device 1 60A are utilized in many implementations of the subscriber user interface 
180 (FIG. 1). In one implementation, the navigation pad 420 allows the subscriber to browse 
the subscriber user interface 180 (FIG. 1). In a non-limiting example, a free floating arrow, 
similar to a conventional personal computer mouse pointer, could be displayed and controlled 

30 by the navigation pad 420 on the client command device 160A. In another example, the 

arrows on the navigation pad 420 could enable the subscriber to cycle through selectable 
elements. In one implementation, pressing the right arrow on the navigation pad 420 causes 
the next selectable element on the screen to be highlighted or come into focus. When the 
element is shown as highlighted or in focus, then that element is currently active. In most 
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implementations, the subscriber can perform a function on an element when it is active. In 
one implementation, when the subscriber strikes the select button 430 key, then the active 
element is selected. The select button 430 can be used for a variety of functions, examples 
including, among others, enabling a certain transaction configuration option, disabling a 
5 certain transaction configuration option, and maneuvering to different screens in the 

interface. In addition to the select button 430, there are other keys on the client command 
device 160A termed function keys 440. The function keys are used, among other things, for 
performing functions on non-highlighted elements. In one implementation, the "C" button of 
the function keys 440 can be pressed to exit from a particular screen. 

10 A one button buy 4 1 0 key shown on the client command device 1 60 A illustrates one 

implementation of a special key used in conjunction with the transaction configuration 
module 100, though not present in all embodiments of the present invention. In an example 
embodiment, the one button buy 410 could be utilized by the subscriber when completing a 
single execution transaction. As mentioned above, the single execution transaction allows the 

15 _z user to initiate and complete a desired purchase with one execution. In the implementation 
depicted in FIG. 4, pressing the one button buy 410 key is the single execution of the single 
execution transaction. In a non-limiting example, the subscriber could enable single 
execution transactions through the use of the transaction configuration module 100. Once 
enabled, the subscriber can search for items to purchase and when a desired item is found, 

20 that subscriber can purchase the item simply by pressing the one button buy 4 1 0 key. In an 

alternate implementation, the one button buy 410 key could be enabled under limited 
circumstances, for example, in association with the purchase of certain items, when a certain 
user is logged in, or when the price of an item is below a set value. 

In alternate embodiment, one button buy 410 is not an actual button but a slide switch 

25 on the right or left side of the top view client command device 160 A requiring activation with 

a push towards the front or rear of client command device 160 A. This slide switch could be 
used, among other things, to avoid accidental presses. 

In another embodiment, the client command device 1 60A is implemented without the 
one button buy 410 key. In a non-limiting example, the client command device 160A could 

30 be a standard TV remote control. 

In some of the discussion below, reference is made to numerous diagrams depicting 
screen shots of the subscriber user interface 180 (FIG. 1). These screen shots depict different 
implementations of the subscriber user interface 1 80 (FIG. 1). The screen shots do not 
represent a flow of configuration screens in the subscriber user interface 180 (FIG. 1). The 
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screens displayed are independent implementations unless otherwise stated in the description 
below, and these screens may be accessed in a variety of ways, examples including, among 
others, from a general settings menu or from within a particular application. In one 
implementation, the subscriber could make a selection within a particular application, such as 
video on demand, to go to a transaction configuration screen. 

It should be understood that when the title of a particular subscriber user interface 1 80 
(FIG. 1) screen is referenced, all the elements in the screen or portion of the screen associated 
with that title are being referenced. One of ordinary skill in the art should recognize that the 
subscriber user interface 180 (FIG. 1) could be implemented in a variety of different manners 
instead of or in addition to those shown in the figures. 

FIG. 5 is a diagram of subscriber user interface 180A, an example implementation of 
subscriber user interface 180 (FIG. 1), depicting a transaction configuration options 540 
screen. This implementation illustrates one manner in which the transaction configuration 
module 100 may be configured. In one implementation, the administrator can allow the 
subscribers in the system access to only this option. Thereby, the administrator can dictate, 
preferably through the administrative user interface 190 (FIG. 1), that the transaction 
configuration module 100 (FIG. 1) enable this screen of the subscriber user interface 180 
(FIG. 1) to be displayed when the subscriber accesses the subscriber user interface 180 (FIG. 
1), such as via a general settings menu or other path. In an alternate implementation, the 
screen depicted in FIG. 5 could be one of many presented to a subscriber upon accessing the 
subscriber user interface 180 (FIG. 1). 

The subscriber has two choices in the implementation shown in FIG. 5. The 
subscriber can use the client command device 160 A (FIG. 4) to manipulate the up and down 
arrows on the navigation pad 420 (FIG. 4) to toggle between the two available selections. If 
the subscriber highlights the disable single execution transaction 520 option and presses the 
select button 430 (FIG. 4), then the subscriber will not be able to complete a purchase using a 
single execution transaction. If the subscriber highlights the enable single execution 
transaction 510 and presses the select button 430 (FIG. 4), then the subscriber will be able to 
complete a single execution transaction and thereby initiate and complete an entire purchase 
simply by executing one step. In FIG. 5, the enable single execution transaction 510 option 
has been highlighted and selected, thus the subscriber will have the ability to initiate and 
complete a purchase in a single execution. In a non-limiting example, the subscriber might 
desire to purchase a NVOD movie. If the enable single execution transaction 510 option has 
been selected by the subscriber to be implemented as that subscriber's transaction process, 
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then the subscriber would be able to merely press a single button on the client command 
device 160A (FIG. 1) in order to initiate and complete a NVOD movie purchase. In one 
implementation, this button could be the one buy button 410 shown in FIG. 4. The 
transaction process in this implementation involves one execution, the pressing of a button on 
5 a remote. It is expressly noted that an execution is an action instigated by a subscriber and 

should not be confused with an execution by a device. The client device 140A would not 
prompt the subscriber for any other actions, as it would if the disable single execution 
transaction 520 option is selected, such as a screen requesting confirmation of the desire to 
purchase, the entering of a PIN and/or username info, etc. Instead, the process would 
10 complete the purchase and would allow access to the desired NVOD movie at the prescribed 

time. 

A single execution transaction could be very advantageous to certain types of 
~ customers. The transaction processes of the systems in the prior art could prove quite tedious 
: to a person living in a single adult household. Prior art systems might require an adult living 

15 ~ alone to enter an authentication PIN and confirm every purchase. The requirements exist 
despite the fact that they are likely to be the only subscriber making such requests from the 
client device 140A (FIG. 1) of that subscriber. In the embodiment of the present invention 
illustrated in FIG. 5 and described above, the single adult could configure the single adult's 
client device 140 A (FIG. 1) to initiate and complete a purchase based on one execution, a 

20 single execution transaction. In the environment of a single adult home, the likelihood of an 

unauthorized person making such purchases is quite remote. The ease of use for such 
customers is a great advantage that comes with little or no risk of unauthorized purchases. If 
any user, however, is unable to control such functionality, the STS headend 120 (FIG. 1) can 
terminate this functionality. 

25 In an alternate embodiment, the screenshot depicted in FIG. 5 could be a transaction 

configuration options 540 screen for a particular type of item of the various available items. 
In a non-limiting example, a subscriber might select the enable single execution transaction 
510 option for video on demand movies. The same subscriber might select the disable single 
execution transaction 520 option for pay-per view events. This would allow the subscriber to 

30 have quick and easy access to purchases of low cost video on demand movies and more 

complicated and secure access to purchases of higher cost pay-per view events. Therefore, in 
this embodiment the selection of enabling or disabling a single execution transaction would 
be associated with a particular type of media content service, such as, for example, video on 
demand 
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FIG. 6 is a diagram of subscriber user interface 180B, an example implementation of 
subscriber user interface 180 (FIG. 1), depicting a first time subscriber registration 610 
screen. In one embodiment, this diagram illustrates a screen that would be encountered by a 
subscriber after the first time that the subscriber selects the enable single execution 
5 transaction 510 option in FIG 5. In order for the media service system 1 10 to process a 

request by the subscriber pursuant to one execution, the system might require stored 
information about the subscriber. In a non-limiting example, if the subscriber orders a movie, 
then the media service system 110 (FIG. 1) may need to have the name of the subscriber, the 
subscriber's address, and billing information such as, for example, an account number. The 

10 screenshot in FIG 6 illustrates a first time subscriber registration 610 screen. As denoted in 

FIG 6, subscriber user interface 180B is presented the first time a subscriber enables a single 
execution transaction. The subscriber user interface 180B enables the subscriber to enter 
subscriber information, such as, for example, a name 620, address 630, and, if applicable, 
credit card 640. In one implementation, a subscriber is given the choice to bill purchased 

15= media services to the account of the subscriber or to charge them to a credit card of the 
subscriber. 

In one implementation, information entered by the subscriber is stored in memory 320 
(FIG. 3) and backed up at the STS headend 120 (FIG. 1). The copy stored at the STS 
headend 120 (FIG. 1) serves to restore the information in the event of power outage to client 

20 - device 140A (FIG. 1). In an alternate implementation, this information is stored at the client 
device 140 A (FIG. 1) in non- volatile read-write memory, either included as part of memory 
320 (FIG. 3) or as separate independent memory, thus allowing for recovery in the event of a 
power outage. An alternative is presented when the client device 140 A (FIG. 1) includes a 
connected storage device, either internally or externally connected to the client device 140A 

25 through a communication or peripheral port, to store information entered by the subscriber. 

Regardless of where the configuration information resides and where it is backed up, the 
subscriber data is accessed in some implementations when a single execution transaction is 
enabled. The subscriber data acquired through the subscriber user interface 1 80 screen 
shown in FIG. 6 enables the media service system 1 10 to initiate and complete a purchase 

30 based on a single execution by the subscriber. In a non-limiting example, when the 

subscriber presses the buy button on the remote after selecting the enable single execution 
transaction 510 (FIG. 5), the purchase can be completed without requesting any additional 
input from the subscriber. In one implementation, the subscriber could be required to enter 
the information via subscriber user interface 180B only one time. Thereby, the subscriber 
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could enable the single execution transaction option without reentering information. The 
transaction configuration module 1 00 could pull the necessary information from a record 
stored elsewhere in memory 320 (FIG. 3), non-volatile memory, or a in a storage device 
connected to client device 140A (FIG. 1). The subscriber would not have to enter the 
personal information unless the subscriber desired to update that information. In a non- 
limiting example, the administrator could implement single execution transactions simply 
based upon the same information used in providing standard service. Other embodiments 
include never accessing such information or requiring it to be entered by the subscriber, 
instead simply applying the purchase to a subscriber record based upon other identification of 
the subscriber. 

FIG. 7 is a diagram of subscriber user interface 180C, an example implementation of 
subscriber user interface 180 (FIG. 1), depicting a purchase options 710 and reminder options 
720 screen. This implementation of the subscriber user interface 180C allows the subscriber 
to choose from among available options under purchase options 710 and options under 
reminder options 720. After the subscriber chooses the desired options, the transaction 
configuration module 100 can implement those chosen options to create a transaction process 
or set of transaction processes. 

In one implementation of this embodiment, the administrator can designate in the 
administrative user interface 190 what options are available to the subscriber, using an 
interface (not shown) resembling that of FIG. 7, as would be understood by the reasonably 
skilled. As illustrated in FIG. 7, the purchase options are grouped into a scrolling window 
730. The administrator can determine the options that are seen by the subscriber in the 
scrolling window 730. As will be described further below, the administrator can select from 
a set of possible options and decide which options are to be made available. The same 
functions could be performed on the set of reminder options 720 that are made available to 
the subscriber. 

When the subscriber enters the subscriber user interface 1 80C depicted in FIG 7, that 
subscriber may choose those options which best suit the subscriber's desires for a transaction 
process. The first scrolling window 730 displays the available purchase options 710. In one 
implementation, the purchase options 710 determine what takes place when a purchase is 
initially conducted, and the reminder options 720 determine events subsequent to the initial 
transaction and/or prior to the commencement of the purchased item. As a non-limiting 
example, reminder options 720 are useful when a subscriber purchases a media content 
service or item to be received by the subscriber at a future time. The first of the purchase 
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options 710 is the PIN required 731 option. When the PIN required 731 option is selected, 
the implemented transaction process will include a PIN entry request. This PIN entry request 
will prompt the subscriber for a secure set of numbers, characters, or combination thereof. In 
a non-limiting example, the subscriber could request a pizza to be delivered, and the media 
5 service system 1 1 0 would prompt the subscriber to enter an authentication PIN to ensure that 

the subscriber is authorized for such activities. If the PIN required 73 1 option is unselected, 
then it will not be included in the transaction process implemented by the transaction 
configuration module 100. This is true for many of the available options in FIG. 7. 

In an alternate embodiment, the PIN required 73 1 option could be specific to a 
10 particular subscriber or specific level of authorization. Thereby, the client device 140A (FIG. 

1) would keep track of more than one PIN for different subscribers and different levels of 
authorization. In one implementation, a master PIN could be assigned to an individual 
- subscriber, such as, for example, the head of the household. Another PIN could be a limited 
l.C PIN assigned to another individual subscriber, such as, for example, the child in the family. 
15 ^ Certain purchases could be placed using the limited PIN and certain purchases would 

required the master PIN. In another example implementation, a PIN could be used, not to 
authenticate a purchase, but to authenticate a block of a purchase. A blocking PIN could be 
enabled to block all or certain purchases made by the client device 140A (FIG. 1). 

When the subscriber selects the multiple PINs required 732 option, the transaction 
20 £ : process will be implemented to include a multiple PIN entry request. Upon making a request 
: for purchase, the subscriber will be required to enter multiple PINs before the transaction 

process will proceed. Similar to the PIN required 73 1 option, this adds even more security to 
the transaction process. The multiple PINs required 732 option enhances that security by 
requiring that the subscriber be aware of at least two authorization PINs. Entering multiple 
25 PINs may be frustrating to some subscribers, especially those living at home. In this 

embodiment, the number of PINs needed for the multiple PINs required 732 option is 
configured by the administrator. In an alternate embodiment, the administrator could 
configure a range for the number of multiple PINs required and then allow the subscriber to 
choose from that range. The multiple PINs required 732 option is mutually exclusive with the 
30 PIN required 73 1 option, and this is indicated by the crosshatching of multiple PINs required 

732 option's activation button. 

The subscriber login required 733 option adds a subscriber login to the transaction 
process. If the subscriber selects this option of the purchase options 710, then that subscriber 
will be required to enter a subscriber login consisting of a user name and password in order 
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for a transaction process to proceed. As will be discussed below, the subscriber login can be 
used for a variety of different applications, such as authentication and subscriber 
identification for subscriber specific services. 

The confirmation screen required 734 option can be selected by the subscriber when it 
5 is desired that a purchase request be followed by a confirmation screen. Pursuant to selecting 

this confirmation screen required 734 option, a transaction process could include the 
presentation of a screen that prompts the subscriber to confirm that the subscriber intends for 
a purchase to be made and is aware that the transaction process is underway. 

The notification icon displayed 735 option can be selected by a subscriber to provide 

10 a notification when certain transaction processes are activated by the transaction 

configuration module 100. In a non-limiting example, the subscriber might have chosen the 
PIN required 73 1 option to be implemented as a transaction process. Therefore, this 
subscriber might want a notifier to be displayed by the Presentation System 150A to indicate 
that a purchase can be completed by entering only one PIN. In an example situation, the 

15 subscriber might be cognizant that other subscribers in the household, although not 

authorized to make purchases, are aware of this PIN. Thus, the subscriber would want to be 
notified of the unauthorized subscriber's ability to complete purchases. This notifier option 
shall be described in further detail below. 

The charge credit card 736 option can be selected by the user to be implemented as 

20 part of the transaction process. When activated, the charge credit card 736 option will 

stipulate the billing method by which the purchase is processed. If selected, then the 
associated charges could be billed to a credit card, rather than the subscriber access bill, such 
as a cable TV bill as one example. 

The next section of options depicted in the screenshot of FIG 7, are the reminder 

25 options 720. These options pertain to settings regarding reminders that are prompted by the 

media service system 1 10 to be displayed to the subscriber. The reminder prior to viewing 
742 option will require the system to prompt the subscriber with a reminder prior to the 
viewing of a purchased item. The crosshatched filling in selection box 746 indicates to the 
subscriber this reminder option may be selected to the exclusion of selection box 745. The 

30 second reminder option depicted in FIG. 7 is reminder requiring authentication PIN prior to 

viewing 743, and it activates a reminder requiring a PIN entry by the subscriber. In an non- 
limiting example, if the subscriber were to purchase a pay-per view event two weeks in 
advance, then the system would prompt that subscriber at some point, prior to viewing, with a 
reminder. That reminder would require the subscriber to enter a PIN for authentication 
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purposes. If that PIN was not entered or entered incorrectly, the transaction process may 
provide the subscriber a subsequent chance to enter a PIN, or after exhausting one or few 
additional chances to enter a PIN, the purchase may be abandoned and the purchase may 
become void. Herein, an incorrect PIN entry should be assumed to include the exhaustion of 
5 a number of additional attempts to provide a subscriber a chance to enter a correct PIN. More 

reminder options may be available to the subscriber and can be accessed by scrolling down in 
the reminder options 720 window 740. 

FIG. 8 is a diagram of subscriber user interface 1 80D, an example implementation of 
subscriber user interface 180 (FIG. 1), depicting a reminder options 810 screen. This 
10 implementation of a reminder options 810 screen differs from the one depicted in FIG. 7 and 
potentially could be associated with different implementations of the media service system 
C 1 1 0 (FIG. 1) or its applications. In this implementation, the user, either the administrator or 
•jj the subscriber, is able to choose among available reminder options 810. The reminder 
:f options 810 screen shown in this figure allows the user to set five reminders. A reminder is 
15 activated by selecting its associated activation button, such as reminder #1 820 and activation 

"-"T button 850. If all are unselected, then no reminders will be provided to the subscriber 
^ regarding a purchase. In an example implementation, all reminders could be unselected when 
the subscriber is presented with the reminder options 810 screen for the first time. If the 
subscriber desired a reminder to be activated, then that subscriber could select the activation 
20 = . s button associated with that reminder, such as activation button 850 associated with reminder 
#1 820. After enabling reminder #1 820 by selecting activation button 850, the subscriber 
can further define the reminder feature via the PIN required 830 field 831 and the time prior 
to event 840 field 841 . In a non-limited example, the subscriber could dictate that reminder 
#1 820 have a PIN requirement by selecting the 83 1 field and toggling the response to YES. 
25 When the subscriber is subsequently prompted by the client device 140A (FIG. 1) with a 

reminder about a purchase, then that reminder will require the user to enter a PIN. If the 
subscriber enters the correct PIN, then the purchase process continues. If the PIN is 
incorrect, then the purchase may be voided and subscriber may not receive the item desired. 
In addition to setting a PIN requirement, the subscriber can also dictate or configure at what 
30 time a reminder is shown relative to the start time of a media content service or relative to the 

time that the purchase transaction was completed. In a non-limiting example, the subscriber 
can determine that reminder #1 820 require a reminder be shown to the subscriber at the start 
of the viewing of the requested media content, or in other words immediately prior to the start 
of the requested media content. The subscriber can change the time at which the reminder is 
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shown by selecting the time prior to event 840 field 841 that is associated with reminder #1 
820. The settings for time prior to event 840 range in this implementation from "At Start" to 
"1 week". When a reminder is activated, it is assigned a default value for time prior to event 
840. In one implementation, the administrator configures the default value and the range of 
available settings for time prior to event 840. 

The subscriber can set up to five reminders in the implementation of the subscriber 
user interface 180C shown in FIG. 8. If the subscriber accepts the settings shown in FIG. 8, 
then that subscriber would be prompted by the two reminders associated with selected 
activation buttons 850 and 860. After requesting a purchase, the client device 140A (FIG. 1) 
would prompt the user with a reminder notice thirty minutes before the event, in association 
with reminder #3 870, and this reminder notice would require the subscriber to enter a PIN. 
Secondly, the client device 140A (FIG. 1) would prompt the subscriber with another 
reminder notice, associated with reminder # 1 820, at the start of the event, and this reminder 
notice would not require a PIN entry. 

In one implementation the reminders activated in the reminder options 810 screen 
could be associated with all purchases. Therefore, a subscriber could be prompted with the 
activated reminders whenever the subscriber purchased any kind of item. In another 
implementation, the settings for reminder options 8 1 0 shown in FIG. 8 could apply only to a 
specific purchase. In a non-limited example, the reminder #1 850 and reminder #3 860 
shown as activated in FIG. 8, would be prompted to the subscriber when a pre-determined 
item was purchased such as, for example, a NVOD, VOD, or pay -per view event. 

FIG. 9 is a diagram of subscriber user interface 180E, an example implementation of 
subscriber user interface 180 (FIG. 1), depicting a video on demand transaction configuration 
options 910 screen. This diagram depicts an interface where transaction configuration 
options are defined in association with a specific application within the media service system 
110 (FIG. 1). FIG. 9 is a depiction of an interface where a subscriber can choose among the 
options shown in subscriber user interface 180E. It should be apparent to one of ordinary 
skill in the art that the application specific interface of FIG. 9 could similarly be provided for 
any application in the media service system 110 (FIG. 1), not just video on demand. 

Use of the configuration tools in FIG. 9 allows the subscriber to choose certain 
transaction configuration options for video on demand purchases. Therefore, in one 
implementation the transaction configuration options selected in the video on demand 
transaction configuration options 910 screen can apply to all video on demand purchases. 
The first set of transaction configuration options presented to the subscriber in the video on 
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demand transaction configuration options 910 screen regards billing preferences. The option 
selected by the user for billing 920 will dictate the manner in which charges associated with 
video on demand purchases will be billed to the subscriber. The transaction configuration 
options provided in billing 920 are mutually exclusive options. With mutually exclusive 
5 options, the OR 922 indicates that either the charge cable bill 924 option can be selected or 

the charge credit card 925 option can be selected. Both options may not be selected at the 
same time. Therefore, when the subscriber selects the charge cable bill 924 selection box 
921, the charge credit card 925 selection box 923 will be shown as filled with crosshatching 
as depicted in FIG. 9. The crosshatching shown over the selection box 922 illustrates that the 

10 charge credit card 925 option has not been selected. If the subscriber desires for a video on 

demand purchase to be billed to a credit card, then that subscriber can select the 923 selection 
box. This new selection would cause the charge cable bill 924 selection box 921 to be filled 
with the crosshatching, indicating an unselected state. 
y The second set of transaction configuration options presented to the subscriber in the 

15 s. video on demand transaction configuration options 910 screen regards reminders. The 
: ;4 reminders 930 area of the interface presents two transaction configuration options to the 
subscriber. Unlike the billing 920 options, the reminders 930 options are not mutually 
exclusive; therefore, both options can be activated at the same time. The subscriber can 
5 select the reminder at start 93 1 selection box 932 if it is desired that a reminder be presented 

20 if at the start of the event. Similarly, the subscriber can select the reminder following purchase 
933 selection box 934 to activate this reminder. Such a selection would require a reminder to 
be shown to the subscriber immediately following a video on demand purchase. 

The third set of transaction configuration options presented to the subscriber in the 
video on demand transaction configuration options 910 screen regards request parameters. 

25 This set of transaction configuration options illustrates a significant advantage enabled by the 

transaction configuration module 100 (FIG. 1). By offering application specific transaction 
configuration options, both the provider and the subscriber of the media service system 110 
can benefit from very specific transaction processes. Transaction processes where the 
subscriber can configure the subscriber's preferences in accordance with the options made 

30 available by the administrator. The request parameters 940 options are options that are 

specifically associated with video on demand purchases. In one implementation, the 
administrator could offer a cost savings to those subscribers who are willing to purchase a 
video on demand and wait a period of time until traffic on the STS transmission system 130 
(FIG. 1) is reduced. The administrator could provide this delayed session at a lower cost 
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based on bandwidth efficiencies, thus charge the subscriber a lower cost. In one 
implementation, the subscriber could enable these cheaper purchases by selecting the delayed 
session (economical) 943 selection box 944. If the subscriber was unwilling to accept such 
delayed sessions, then that subscriber could mandate that all video on demand purchases be 
immediate and without a potential discount. This could be done by selecting the immediate 
session (premium) 941 selection box 942. The request parameters 940 options are mutually 
exclusive such that one is selected at the exclusion of another. The settings illustrated in FIG. 
9 show the immediate session (premium) 941 option as selected and the delayed session 
(economical) 943 as unselected. The crosshatching filling selection box 944 indicates that 
the delayed session (economical) 943 is unselected. 

In another embodiment, the request parameters 940 can also include a threshold field 
for which a subscriber enters a dollar amount that serves as a threshold for the maximum 
purchase price. When invoking a transaction, such as a single execution transaction, the 
subscriber's transaction process proceeds when the intended purchase price is less than the 
threshold. In the event that the purchase price exceeds the threshold, a barker is displayed 
expressing that the threshold value has been exceeded and subscriber input is requested to 
complete the purchase. 

The fourth set of transaction configuration options presented to the subscriber in the 
video on demand transaction configuration options 910 screen regards general settings 950. 
The general settings 950 transaction configuration options allow the user to enable a 
subscriber login required 95 1 option and a notification icon displayed 953 option. Both of 
these options can be enabled at the same time. The subscriber will be required to login to 
complete a video on demand purchase if the subscriber login required 951 selection box 952 
is selected. The subscriber login option will be described in further detail below. If the 
subscriber selects the notification icon displayed 953 selection box 954, a notification icon 
will be provided to a subscriber considering a video on demand purchase. The notification 
icon option will be described in further detail below. 

The fifth set of transaction configuration options presented to the subscriber in the 
video on demand transaction configuration options 910 screen regards PINs. As previously 
mentioned, the subscriber is required to enter an authentication sequence of number, 
characters, or combination thereof when a PIN option is enabled. If the PIN is entered 
incorrectly then the purchase can be voided. The options in the PINs 960 section are 
mutually exclusive. The PIN required 961 option can be selected at the exclusion of the 
multiple PINs required 963 option. If the PIN required 961 option is selected, then the 



24 



Docket No. A-7371 

subscriber will have to enter one PIN to complete a video on demand purchase. If the 
multiple PINs required 963 option is selected, then the subscriber will be required to enter 
multiple authentication PINs to complete a video on demand purchase. In one 
implementation, the administrator determines the number of PINs required when the multiple 
5 PINs required 963 option is selected. In another implementation, the subscriber could 

subsequently configure the number of PINs required for the multiple PINs required 963 
option. 

As previously described, a transaction process can be implemented for all purchases 
or it can be implemented for specific kinds of purchases. In an implementation involving the 

10 video on demand transaction configuration options 910, a transaction process is implemented 

specifically for VOD purchases. When the subscriber accepts the selections shown in FIG. 9 
for the video on demand transaction configuration options 910, a transaction process is then 
generated for VOD purchases. Given the selections shown in FIG. 9, the transaction process 
~ could dictate that a VOD purchase be billed to the cable bill, prompt the subscriber with a 

15 reminder at the start of the VOD, accept only immediate VOD sessions, and require the 

subscriber to enter a PIN when requesting the VOD purchase. In one implementation, this 
transaction process could be assigned to all subscribers purchasing VODs on a particular one 
of the client devices 140 (FIG. 1). In another implementation, this transaction process could 
be assigned to an individual subscriber of one of the client devices 140 (FIG. 1) and be 

20 activated when that subscriber logs in. 

In an example embodiment, the subscriber can be enabled to make the selections 
described above, in relation to the video on demand transaction configuration options 910, 
through the use of the client command device 160 A (FIG. 1). In a manner previously 
described, the subscriber user interface 180 (FIG. 1) could provide a free floating arrow to 

25 select objects or could allow the subscriber to press an arrow key to cycle through the 

selectable objects. 

FIG. 1 OA is a diagram of subscriber user interface 1 80F, an example implementation 
of subscriber user interface 180 (FIG. 1), depicting a PIN entry 1010 screen. In one 
embodiment, the screen depicted in FIG. 1 OA could be presented to the subscriber when that 
30 subscriber enabled a PIN entry option. In a non-limiting example, the subscriber could select 

the activation button for the PIN required 731 (FIG. 7) option supplied as one of the purchase 
options 710 (FIG. 7) depicted in FIG. 7. If this was the first time the subscriber had enabled 
the PIN required 731 (FIG. 7) option, then the media service system 110 (FIG. 1) might have 
to establish a secure PIN sequence. Thereby, the transaction configuration module 100 (FIG. 
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1) could prompt the subscriber with the PIN Entry 1010 screen depicted in FIG. 10A. From 
the PIN Entry 1010 screen, the subscriber could enter a 4 digit PIN 1020 made up of 
characters, numbers, or a combination thereof. After entering the 4 digit PIN 1020, the 
subscriber could confirm the PIN by re-entering it into the confirm PIN 1030 boxes. Once an 
5 acceptable 4 digit PIN 1020 was entered, the media service system 1 10 (FIG. 1) could store 

the PIN in order to authenticate purchases in the future. In one implementation, the media 
service system 110 (FIG. 1) could store the PIN in memory 320 (FIG. 3) in the DHCT 140A 
(FIG. 3). In an alternate implementation, the media service system (FIG. 1) could store the 
PIN in the administrative transaction configuration module 170 (FIG. 1) in the STS headend 

10 120 (FIG. 1). In addition to prompting the user with the PIN entry 1010 screen the first time a 

PIN option is enabled, the media service system might also be configured, by administrator or 
subscriber, to require a new PIN entry 1010 screen to be presented every time the PIN entry 
~%. option is re-enabled. 

FIG. 1 0B is a diagram of subscriber user interface 180G, an example implementation 

15 of subscriber user interface 180 (FIG. 1), depicting a multiple PIN entries 1040 screen. The 

multiple PIN entries 1040 screen allows the subscriber to create the necessary PINs when a 
multiple PIN entry has been enabled. In one example implementation, the subscriber could 
enable the multiple PINs required 963 (FIG. 9) option in the video on demand transaction 
configuration options 910 (FIG. 9) interface screen depicted in FIG. 9. To implement this 

20 option, the media service system 110 (FIG. 1) might need to acquire the PINs from the user 

through the multiple PIN entries 1040 interface screen. When prompted with the multiple 
PIN entries 1040 screen, the subscriber could enter the desired authentication sequences into 
the prescribed areas for PIN #1 1050, PIN #2 1060, and PIN #3 1070. Once the subscriber 
had successfully entered the PINs into the appropriate areas, the subscriber could store those 

25 PINs in the media service system 110 (FIG. 1) by selecting the "A" 1080 key. In one 

implementation this "A" 1080 key could be one of the function keys 440 (FIG. 4) on client 
command device 160 A (FIG. 4). Furthermore, the subscriber could use the client command 
device 160A (FIG. 4) select button 430 (FIG. 4) to activate the "SEL" 1090 icon and the 
navigation pad 420 (FIG. 4) to toggle between PINs for entry. 

30 The methods of PIN entry depicted in FIG. 10A and 10B are provided as examples of 

different means by which the media service system 110 (FIG. 1) can acquire a PIN from the 
subscriber. One of ordinary skill in the art will recognize that many other methods could be 
employed to implement a PIN option, examples including, among others, providing an 
administrator configured PIN or subscriber submission of a PIN via mail or fax. 
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FIG. 1 1 is a diagram of subscriber user interface 180H, an example implementation of 
subscriber user interface 180 (FIG. 1), depicting a video on demand 1 120 screen. This 
implementation of the subscriber user interface 180 (FIG. 1) illustrates an example 
implementation of the notifier option provided by the media service system 110 (FIG. 1). As 
5 previously mentioned, the media service system 110 (FIG. 1) may provide to the subscriber a 

notifier option such as the Notification Icon Displayed 736 option shown in FIG. 7. The 
notifier option can be utilized to notify the subscriber of a particular transaction process that 
is currently enabled. 

In a non-limiting example, the subscriber may have enabled a single execution 

10 transaction option. As previously described, a single execution transaction allows the 

subscriber to initiate and complete a purchase of an item by simply executing one action. 
This option provides a powerful tool for the subscriber, but in some instances, it may incur a 
risk of inadvertent purchases. To avoid such inadvertent purchases, the subscriber may 
choose to enable a notifier option. In one implementation, once the subscriber has enabled a 

1 5 notifier option, a notification will be displayed to that subscriber whenever a single execution 

transaction can be completed. The video on demand 1110 screen demonstrates a non-limiting 
example of the notifier option. It can be assumed for this example that the subscriber has 
previously enabled single execution transactions for VOD purchases. Thus, a notification 
icon 1 100 is displayed when the subscriber is viewing the video on demand 1110 purchase 

20 screen depicted in FIG. 1 1 . In this video on demand 1110 screen, the subscriber can browse 

through a list of available movies 1 120. In one implementation, the subscriber could browse 
through the available movies by pressing the up and down arrows on the navigation pad 420 
(FIG. 4) on the client command device 160A (FIG. 4). The subscriber could select a movie 
by pressing the select button 430 (FIG. 4). The subscriber could watch a preview of the 

25 movie in the video display area 1 1 50 of FIG. 1 1 by selecting the "A" 1 1 60 key on the client 

command device 160 A (FIG. 4). A selected movie, such as Traffic 1 130, could be purchased 
by the subscriber simply by pressing the one buy button 1 140. The notification icon 1 100 
warns the subscriber that a purchase can be initiated and completed just by selecting the one 
buy button 1 140. Thereby, the subscriber will be warned of the ramifications of selecting the 

30 one buy button 1 140 whenever the subscriber sees an encircled lighting bolt, the notification 

icon 1100. 

It should be noted that one of ordinary skill in art would recognize that a notification 
icon could be any type of icon used to indicate not only single execution transactions, but 
also any type of transaction process. In an alternate implementation, a notification icon can 
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be used to indicate that a PIN will be required, a credit card will be charged, or a user login 
will be required to complete a purchase. 

FIG. 12 is a diagram of subscriber user interface 1801, an example implementation of 
subscriber user interface 180 (FIG. 1), depicting a notification barker 1200 screen. In this 
5 example embodiment, the notifier option is not a notification icon but a notification barker. 

For this example embodiment, it is assumed that the subscriber has previously enabled a 
single execution transaction option. The single execution transaction option can be 
completed in the video on demand 1210 purchase interface screen by selecting the one buy 
button 1220. In this implementation, the subscriber is warned that single execution 

1 0 transactions are enabled in the video on demand 1210 screen by the notification barker 1 200. 
This notification barker 1200 is a separate screen implemented by the subscriber user 
interface 1801 to be displayed upon entry into the video on demand 1210 screen. The text 
area 1230 in the middle of the notification barker 1200 specifies the particular warning that is 
being supplied to the subscriber. The text area 1230 for the notification barker 1200 depicted 

15 ; in FIG. 12 indicates to the subscriber that single execution transactions have been enabled. 

Thereby, the subscriber is made aware of the ramifications of inadvertently selecting the one 
buy button 1220. In one implementation, the subscriber can dismiss the notification barker 
1200 by selecting the clear key, "C" 1240. In a non-limiting example the "C" 1240 key is 
one of the function keys 440 (FIG. 4) on the client command device 160A (FIG. 4). 

20 In manner similar to the notification icon, the notification barker 1200 can be used to 

indicate numerous enabled transaction processes in addition to single execution transactions. 
In an alternate implementation, the text area 1230 of the notification barker 1200 could be 
used to described the transaction process currently enabled by the media service system 110 
(FIG. 1) for that subscriber. In a non-limiting example, the transaction process specifically 

25 associated with VOD purchases could be described in the text area 1230 of the notification 

barker 1200. In this manner, when the subscriber entered the video on demand 1210 
purchase screen, that subscriber might be aware of the requirements for completing a VOD 
purchase. 

FIG. 13 is a diagram of subscriber user interface 180J, an example implementation of 
30 subscriber user interface 180 (FIG. 1), depicting a subscriber profile setup 1300 screen. The 

subscriber profile setup 1300 is utilized to enable a subscriber login option. A subscriber 
login option allows a particular subscriber to login to the media service system 110 (FIG. 1) 
such that features individual to that subscriber may be enabled. In a non-limiting example, a 
subscriber login may enable a transaction process or set of transaction processes configured 
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by an individual subscriber. The aforementioned examples of transaction processes can be 
associated with a particular subscriber login. The subscriber profile setup 1300 enables the 
subscriber to initialize this subscriber login option. A subscriber could be prompted by the 
subscriber profile setup 1300 the first time that subscriber enables a subscriber login option. 
5 The subscriber can enter a desired user name in the corresponding user name 1310 box. In 

addition, the subscriber can create a password 1320 for this user name 1310 and confirm this 
password sequence in the confirm password 1330 box. The subscriber logins created in the 
subscriber profile setup 1300 can be used for individual subscribers or groups of subscribers, 
such as the adults or the children in a household. 

10 The subscriber profile setup 1 300 also enables the subscriber to configure certain 

general settings to be associated with the newly created subscriber login. In one 
implementation, the transaction configuration options given here are general settings. As 
mentioned above, the subscriber logins can enable specific transaction processes or sets of 
transaction processes. In one implementation, the transaction configuration options enabled 

15 under the subscriber profile setup 1300 could be implemented as a default transaction 

process. This default transaction process could be activated whenever no other transaction 
processes were provided. Therefore, if the subscriber enabled a different set of transaction 
configuration options in another interface, then the subsequent transaction process could 
override the default transaction process. In addition, if the subscriber selects a certain set of 

20 options for a particular kind of purchase, such as a VOD, then the associated transaction 

process could be implemented instead of the default transaction process for that particular 
kind of purchase. 

The first transaction configuration option under the subscriber profile setup 1300 is 
the enable single execution transaction 1340 option. Selecting the option will enable a single 

25 execution transaction as previously described in detail above. In this implementation, the 

enable single execution transaction 1340 option is mutually exclusive with the respect to the 
other options provided in the subscriber profile setup 1300 interface screen. The OR 1343 
depicted in FIG. 13 implies that the subscriber can select either the enable single execution 
transaction 1340 option or any other option provided. When the enable single execution 

30 transaction 1340 option is selected then the subscriber's default transaction process, when 

logged in, can allow the purchase of an item with one execution. The subscriber further has 
the ability to determine how long the enable single execution transaction 1 340 option is 
activated. If the subscriber selects the until logout 1341 option, then that subscriber will be 
allowed to purchase with single execution transactions until that subscriber logs out of the 
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media service system 110 (FIG. 1). Alternatively, the subscriber can select the until timeout 
1342 option to allow single execution transactions until a timeout period expires. In one 
implementation, the timeout period is configurable by the administrator. In another 
implementation, the timeout period is configurable by the subscriber. The activation button 
5 for the until timeout 1342 option is filled with crosshatching in FIG. 13 to indicate that it is a 

mutually exclusive option with respect to the until logout 1341 option and is therefore 
unselected. In other embodiments, the period of activation can be implemented to depend on 
numerous other parameters besides a logout or timeout, examples including, among others, 
the activation of another transaction process, the completion of a certain number of 

10 purchases, and exiting from a particular application. In a non-limiting example, the enable 

single execution transaction 1340 option may be configured to activate when the subscriber 
enters the VOD purchase interface and deactivate when that subscriber exits the VOD 
1 purchase interface. This might prove advantageous when the subscriber wants to logon to the 
VOD purchase interface, make numerous single execution transactions for the different VOD 

15 - items, and then logout. 

In one embodiment, the period of activation for the enable single execution 
transaction 1340 option can be extended by the subscriber prior to expiration by entering 
additional information causing an activation period extension. As a non-limiting example, 
the user may enter a PIN or a password upon the request of an extension to the activation 

20 ~ period with a remote key or by a selection within the subscriber user interface 1 80 (FIG. 1). 

Alternatively, after the expiration of the activation period, the subscriber may be queried to 
enter a PIN or password to extend the single execution transaction period. 

The second option provided is the charge credit card 1350 option. The subscriber can 
select this option if that subscriber desires their purchases to be billed to a credit card. The 

25 third option, display notification icon 1360, enables the notifier option as previously 

described in detail above. In one implementation, the selection of the display notification 
icon could cause a notifier icon, similar to the one depicted in FIG. 1 1 , to be displayed by the 
subscriber user interface 180 (FIG. 1) when a specific transaction process is enabled. The 
subscriber can select the reminder prior to event 1370 option if that subscriber desires this to 

30 be a step in the default transaction process. Furthermore, the subscriber can select the 

reminder requires a PIN 1380 option if the subscriber desires for an authentication PIN to be 
required as part of a reminder to complete a purchase. It should be clear to one of ordinary 
skill in the art that the transaction configuration options shown in the subscriber profile setup 
1 300 could contain numerous other options not depicted. 
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FIG. 14 is a diagram depicting a graphical tree model as a non-limiting example of 
administrative configuration settings provided by the administrative transaction configuration 
module 170 (FIG. 1). As previously described, the administrator of the media service system 
can configure the transaction configuration options that are available to the subscriber. The 
5 administrator is enabled to perform this task through the use of administrative user interface 

190 (FIG. 1) and thereby the administrative transaction configuration module 170 (FIG. 1). 
The administrative configuration settings depicted in FIG. 14, 1410, 1420, and 1430, are 
graphical representations of data stored in the administrative transaction configuration 
module 170 (FIG. 1). The administrative user interface allows the administrator to either 

10 make the options available for configuration by the subscriber or make transaction processes 

implemented from selections of the possible options available to the subscriber. 

The first administrative configuration settings model 1410 is a very simplistic. Under 
this model the administrator can make option level 11411 available to the subscriber, or the 
administrator can dictate that the client device of the subscriber implement a transaction 

15 process based on a selection in option level 1 1411. Therefore, the administrator can give the 

subscriber the ability to choose to enable or disable single execution transactions or the 
administrator can dictate that the subscriber's client device either performs or does not 
perform single execution transactions. 

The second administrative configuration settings model 1420 has three levels of 

20 options. Option level 1 1421 concerns subscriber logins, option level 2 1422 concerns the 

scope of a subscriber login, and option level 3 1423 concerns a notifier option. This 
administrative configuration settings model 1420 illustrates an implementation where an 
administrator chooses a particular transaction process to be provided to the client devices 140 
(FIG. 1). The darkened line 1424 outlines the options selected to create the transaction 

25 process, terminating with the circled end node 1425. This transaction process will enable a 

subscriber to login 1428, enable subscriber to login to a session 1427, and display a 
notification icon 1429 in association with the activated transaction process. 

The third administrative configuration settings 1430 model has four option levels. 
The administrator has the ability to provide these option levels to the subscriber. If the 

30 administrator provides these options, then the subscriber can choose among them and 

subsequently have transaction processes implemented based on those choices. 

In one example embodiment, the administrative configuration settings, such as 1430, 
are provided to the administrator by the administrative user interface 190 (FIG. 1) in a format 
similar to their graphical representation in FIG. 14. In another implementation, the 
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administrative user interface 190 (FIG. 1) is a command line interface where the 
administrator configures the available options and/or transaction process through the entry of 
certain commands. One of ordinary skill in the art will recognize that there are a variety of 
different methods by which to implement the functionality provided by administrative user 
5 interface 190 (FIG. 1). 

FIG. 1 5 is a diagram that depicts the administrative user interface 1 90 A, an example 
embodiment, enabled by the administrative transaction configuration module 170. The 
administrative user interface 190A enables the administrator to determine what options are 
available and to whom they are distributed. The administrative user interface 190A provides 

10 an interface screen to configure allowable general settings 1510, notifiers 1520, PINs 1530, 

billing 1540, subscriber login 1550, and reminders 1560 options. In one implementation, the 
administrator can configure what reminders 1560 options are available and to whom they are 
available. After selecting the reminders 1560 tab, the administrator will be presented with the 
possible reminder options window 1 561 . The administrator can choose from among the 

15 possible reminder options window 1561 those options to be made available to the subscriber. 

In a non-limiting example, the administrator can add the options to the chosen reminder 
- options window 1563 by selecting an option in the possible reminder options window 1561 
and then selecting the ADD 1562 button. Once an option has been added to chosen reminder 
options window 1563, it can be removed by selecting the option and then selecting the 

20 remove 1 564 button. In one implementation, those options that are placed into the chosen 

reminders options window 1563 are subsequently provided to the subscriber where they can 
be chosen and then implemented as transaction processes. 

Not only does the administrative user interface 1 90A enable the administrator to 
determine what options are available to the subscriber, it also enables the administrator to 

25 determine which subscribers are provided with the chosen options. In a non-limiting, 

example the administrator can dictate what regions of the media service system 1 10 (FIG. 1) 
are provided with the chosen options by making selections in the regions where available 
window 1570. In the implementation depicted in FIG. 15, the north region 1571 and the 
eastern region 1572 have been selected to receive the chosen options. In this implementation, 

30 the media service system 1570 has been broken into four regions and only the client devices 

140 (FIG. 1) in those regions whose activation buttons are selected by the administrator will 
receive the chosen options. In addition to defining the areas of distribution of chosen 
transaction configuration options to regions, the administrator can restrict and permit 
distribution of these options to particular client devices. The subscribers to exclude 1580 



32 



Docket No. A-7371 

window enables the administrator to restrict options from being provided to particular 
subscribers by entering the subscriber identification number in the subscriber identification 
box 1581. In one implementation, multiple subscriber identification numbers could be 
entered separated by commas. This implementation provides the administrator with many 
5 features. In a non-limiting example, the administrator might desire to deny delinquent 
customers or customers with bad credit from gaining access to certain options. In a non- 
limiting example, delinquent customers may not be provided the option to charge to a credit 
card. In addition, the administrator could deny those customers with a history of making 
numerous inadvertent purchases the ability to enable single execution transactions. Not only 

10 can the administrator deny particular subscribers, but the administrator may also include 

particular subscribers by using the subscribers to include window 1 590. The subscriber 
identifications entered in the subscriber identification box 1591 will have access to the 
chosen options although their region has been excluded. In this manner, the administrator 
2 could give preferential treatment to subscribers with exceptional credit or good payment 

15 =; histories. In a non-limited example, the administrator might want to deny single execution 
purchases to specific areas of the media service system 110 (FIG. 1) but singularly allow 
them to the good customers in that same area. 

In one embodiment, the subscriber identification numbers could relate to particular 
subscribers using a subscriber login to access the media service system 110 (FIG. 1) through 

20 one of the client devices 140 (FIG. 1). In an alternate embodiment, the subscriber 

identification number could correspond to a particular one of the client devices 140 (FIG. 1). 
In a non-limiting example, the subscriber identification could be implemented like a unique 
hardware address within the client device. 

It should be noted that one of ordinary skill in the art would recognize that the regions 

25 where available window 1570, the subscribers to exclude window 1580, and the subscribers 

to include window 1590 could apply specifically to the reminders 1560 options or more 
generally to all the options as a whole. Furthermore, the embodiment depicted in FIG. 1 5 is 
merely one example of the variety of ways in which the administrative user interface 170 
(FIG. 1) could be provided. 

30 FIG. 16 is a diagram of subscriber user interface 1 80K, an example implementation of 

subscriber user interface 180 (FIG. 1), depicting a remote subscriber user interface 1600 
screen. In one implementation, the subscriber might be able to access the remote subscriber 
user interface 1600 via the internet. Thereby, a subscriber could select among the available 
transaction configuration options and have these selections implemented as transaction 
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processes in that subscriber's client device. The subscriber could select from the given tabs 
to set general settings 1610, notifiers 1620, PINs 1630, billing 1640, subscriber login 1650, 
and reminders 1660 options. The interface layout depicted in FIG. 16 is similar to the 
subscriber user interfaces previously described. The reminders 1660 options section depicted 
5 allows the subscriber to enable reminders and configure the parameters associated with those 

reminders. In a non-limiting example, the subscriber could access the remote subscriber user 
interface 1600 in an ordinary internet browser and select the desired transaction configuration 
options. The next time that subscriber used the subscriber's client device, the prescribed 
options would be implemented in the appropriate transaction processes when making 

1 0 purchases using the media service system 1 1 0 (FIG. 1 ). 

In addition to the subscriber user interface 1600 variation shown in FIG. 16, many 
other variations are possible. In a non-limiting example, the subscriber user interface 180 
(FIG. 1) could be implemented as voice command software. The voice command software 
~ could be a component within the client device 140 A (FIG. 1) or a device coupled to the client 

15 - device 140A (FIG. 1) over a communications link. The voice command software could 
enable the user to give voice commands regarding choices of available transaction 
configuration options. After commencing a voice command session of the subscriber user 
interface 180 (FIG. 1), the client device 140A (FIG. 1) could implement the appropriate 
transaction processes. 

20 The media service system 110 (FIG. 1) utilizes standard encryption techniques to 

protect the sensitive subscriber information requested in the subscriber user interface 180 
(FIG. 1). The embodiments described above, in many cases, will increase the security of 
subscriber transactions by requiring less repetitive entries of sensitive information. In 
addition, the subscriber user interface 180 (FIG. 1) may show only partial amounts of 

25 sensitive information when used for verification purposes. 

The transaction configuration module of the present invention can be implemented in 
hardware, software, firmware, or a combination thereof. In addition, the transaction 
configuration module can be implemented in a distributed fashion in more than one device in 
the system. In the preferred embodiment(s), the transaction configuration module is 

30 implemented in software or firmware that is stored in a memory and that is executed by a 

suitable instruction execution system. If implemented in hardware, as in an alternative 
embodiment, transaction configuration module can be implemented with any combination of 
the following technologies, which are all well known in the art: a discrete logic circuit(s) 
having logic gates for implementing logic functions upon data signals, an application specific 
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integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate 
array (s) (PGA), a field programmable gate array (FPGA), etc. 

The transaction configuration module, which comprises an ordered listing of 
executable instructions for implementing logical functions, can be embodied in any 
computer-readable medium for use by or in connection with an instruction execution system, 
apparatus, or device, such as a computer-based system, processor-containing system, or other 
system that can fetch the instructions from the instruction execution system, apparatus, or 
device and execute the instructions. In the context of this document, a "computer-readable 
medium" can be any means that can contain, store, communicate, propagate, or transport the 
program for use by or in connection with the instruction execution system, apparatus, or 
device. The computer readable medium can be, for example but not limited to, an electronic, 
magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or 
propagation medium. More specific examples (a nonexhaustive list) of the computer- 
readable medium would include the following: an electrical connection (electronic) having 
one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) 
(electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only 
memory (EPROM or Flash memory) (electronic), an optical fiber (optical), and a portable 
compact disc read-only memory (CDROM) (optical). Note that the computer-readable 
medium could even be paper or another suitable medium upon which the program is printed, 
as the program can be electronically captured, via for instance optical scanning of the paper 
or other medium, then compiled, interpreted or otherwise processed in a suitable manner if 
necessary, and then stored in a computer memory. 

In concluding the detailed description, it should be noted that it will be clear to those 
skilled in the art that many variations and modifications can be made to the preferred 
embodiments without substantially departing from the principles of the present invention. 
All such variations are intended to be included herein within the scope of the present 
invention, as set forth in the following claims. 
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